t128 document overview
  • 5 Overview

    The AS protocol enables multipoint computer application sharing by allowing a view onto a computer application executing at one site to be advertised within a session to other sites. Each site can, under specified conditions, take control of the shared computer application by sending remote keyboard and pointing device information. This style of application sharing does not require and does not make provision for synchronizing multiple instances of the same computer application running at multiple sites. Instead, it enables remote viewing and control of a single application instance to provide the illusion that the application is running locally.

    An AS session consists of one or more ASCEs which cooperate via the AS protocol to share one or more applications within the session. The AS protocol defines interactions between ASCEs. It does not define interactions between an ASCE and the operating system or input and output devices on the local terminal.

    5.1 Legacy And Base Modes

    The AS protocol supports two modes of operation. Legacy mode is provided for interoperability with an existing installed base of customer terminal equipment. Base mode provides additional features that enable future AS protocol enhancement.

    All ASCEs compliant with this Recommendation shall implement both legacy and base modes. The AS protocol usage of GCC (see clause 7) is defined such that where all ASCEs in a conference support base mode (i.e. there are no pre-existing legacy mode only terminals in the conference), then all ASCEs shall use base mode. It is the ITU’s intention that all future enhancements to the AS protocol shall be by enhancements to base mode.

    A significant proportion of this Recommendation is common to both modes, with the primary differences between the two modes being in the following areas.

  • The manner in which capabilities are exchanged and negotiated: See clause 8.2.
  • The manner in which ASCEs are activated and deactivated: See clause 8.4.
  • The definition and encoding of ASPDUs: See clause 9.

    • Where there are differences between the legacy and base modes of the AS protocol, they are highlighted in the text.

    5.2 AS Concepts

    5.2.1 Desktop and Window Model

    This Recommendation does not assume or require any particular local terminal equipment or terminal environment, nor does it assume or require a particular local terminal window manager or windowing model. For example, it does not assume:

  • that the terminal equipment is a PC or workstation - it may be a dedicated terminal
  • that AS protocol windows correspond to windows managed by a terminal window manager - they may map onto arbitrary areas of the local terminal display
  • that AS protocol desktops correspond to local terminal displays - they may map into local browser or viewer windows, or onto dedicated terminal display areas.

    • While this Recommendation does not assume or require any particular local terminal equipment or terminal environment, the AS protocol does define a logical desktop and window model - consisting of a collection of windows on a desktop. This requires that each active ASCE within an AS session is capable of mapping local terminal environment concepts to and from the AS protocol desktop and window model. The AS protocol desktop and window model supports the following key concepts.

    Desktop The AS desktop is a rectangle defined in virtual desktop coordinates. An ASCE should provide a mapping from the AS desktop to an appropriate local terminal concept.
    Virtual Desktop The virtual desktop is the union of the sizes of the desktops of hosting ASCEs (i.e. ASCEs that are hosting windows - see below). The virtual desktop origin (i.e. pixel 0,0) is defined as being at (top,left).
    Window An AS window is a rectangle defined in virtual desktop coordinates. AS windows may be wholly within, partially within or wholly outside the virtual desktop. An ASCE should provide a mapping from AS windows to an appropriate local terminal window concept.
    Z-order The AS window Z-order defines a window depth ordering between windows on the virtual desktop, such that for two windows, the window higher in the Z-order is in front of and/or may obscure the other.
    Top-most The top-most AS window in the Z-order is in front of and/or may obscure all other windows in the Z-order.
    Bottom-most The bottom-most AS window in the Z-order is behind and/or may be obscured by all other windows in the Z-order.

    Further AS protocol concepts are explained below or in the appropriate protocol description clauses.

    Figure 2 shows an example collection of ASCEs within an AS session - this figure is used throughout this clause to illustrate key AS protocol concepts.

  • ASCE A is full function, viewing and hosting - that is, it both shares windows into the AS session and displays shadow windows shared from other ASCEs. It is executing on a general purpose PC, where the AS desktop and AS windows are mapped directly onto the terminal window manager’s desktop.
  • ASCE B is viewing only - that is, it displays shadow windows shared from other ASCEs but does not itself share windows into the AS session. It is executing on a specialized viewing terminal where the AS desktop and AS windows are mapped into an independently sizable browser/viewer window, which is (currently) smaller than the AS desktop and is scrolled as required to view the entire AS desktop.
  • ASCE C is hosting only - that is, it shares windows into the AS session, but does not display shadow windows. It is executing on a high-end unattended workstation, where the AS desktop and AS windows are mapped directly onto the terminal window manager’s desktop.

    • FIGURE 2/T.128
    Example Collection of ASCEs within an AS Session

    Within an AS session, windows are of the following types.

  • Hosted: Hosted windows are owned by an application executing on the local terminal and are shared into the AS session. For each hosted window, there will be a corresponding shadow window on each peer ASCE (except for the case where an ASCE is hosting only).
  • Shadow: Shadow windows are drawn by the ASCE and correspond to a hosted window on a particular peer ASCE.
  • Local: Local windows are not shared - their output is only visible on the local terminal. An ASCE is only required to track local windows where they obscure a hosted window and where that obscuring prevents the ASCE obtaining valid drawing information for the hosted window.

    • Figure 2 shows (for each ASCE) both the local windows on the actual terminal display and the AS windows on the AS desktop that the ASCE manages via the AS protocol.

  • ASCE A is managing three windows:

  • a shadow window corresponding to the hosted window on ASCE C
    		•
  • a hosted window which is shared into the AS session
    		•
  • a local window - because it obscures the hosted window and on the local terminal that prevents it obtaining valid drawing information for that hosted window.
    		•

    Shadow window C is drawn on the local terminal display by the ASCE - and the other two windows are displayed by the local terminal.

  • ASCE B is also managing three windows:

  • a shadow window corresponding to the hosted window on ASCE A
    		•
  • a shadow window corresponding to the hosted window on ASCE C
    		•
  • the local window from ASCE A - because it obscures the hosted window on ASCE A.
    		•
  • ASCE B does not track the local windows on its terminal display as it does not host windows.
    		•

    Shadow windows A and C are drawn into the browser/viewer window on the local terminal display by the ASCE. The local window is not drawn, but is rather used to compute and draw an obscuring area, which partially obscures shadow window A (shown as a dark area at the bottom right of shadow window A).

  • ASCE C is managing one window: